POJO/DTO/DO/EO/VO/BO/PO/AO的含义和使用 |
您所在的位置：网站首页 › getmapping 入参 › POJO/DTO/DO/EO/VO/BO/PO/AO的含义和使用 |
|
关于POJO/DTO/DO/EO/VO/BO/PO/AO
本文讨论 POJO/DTO/DO/EO/VO/BO/PO/AO 的定义，另外讨论了这些xO在controller、service、dao/mapper层里的使用规范。另外还稍微讨论了controller中是否要 “轻逻辑”，mapper接口的规范等等问题。 前言在我们的java项目中存在各种xO的概念，如POJO/DTO/DO/EO/VO，还有些后端开发可能不太常见的BO/PO/AO。这里结合阿里Java手册以及其他博客的知识总结一下。这些xO一般都具有简单的结构，如setter/getter/toString POJO：Plain Old/Ordinary Java Object，是其他xO的统称。笔者也喜欢用bean来统称这些xO，但后来觉得不准确，因为bean一般指spring容器所管理的beanDTO：Data Transfer Object，用来作为Controller的出参和Service的出参。一般分为两类：Controller的入参叫xxxReqDTO，Service层的出参叫xxxRespDTO。也有很多系统并不分得这么细。DO：Data Object，用来和单表一一对应的实体类。也有资料显示DO是Domain Object（域对象）， EO：Entity Object，实体对象。有些公司用来表示跟表一一对应的类，即相当于DO。PO：记得最初的阿里Java文档定义为Persistence Object，持久化对象，当时文档说是跟表一一对应的，不知道后来的文档为什么改成了DO（难道记错了?） VO：View Object，阿里Java文档中说用来跟前端页面一一对应的对象。偶尔会有用错的情形，比如用来作为Controller层的入参BO：Business Object，阿里Java文档说明由 Service 层输出的封装业务逻辑的对象。不理解AO：Application Object，应用对象，不知道什么用。其实搞这么多xO，有时候真的会影响效率，尤其非大型公司需要快。 【阿里Java手册】 POJO（Plain Ordinary Java Object）: 在本手册中，POJO 专指只有 setter/getter/toString 的简单类，包括 DO/DTO/BO/VO 等。 DO（Data Object）：此对象与数据库表结构一一对应，通过 DAO 层向上传输数据源对象。 DTO（Data Transfer Object）：数据传输对象，Service 或 Manager 向外传输的对象。 BO（Business Object）：业务对象，由 Service 层输出的封装业务逻辑的对象。 AO（Application Object）：应用对象，在 Web 层与 Service 层之间抽象的复用对象模型，极为贴 近展示层，复用度不高。 VO（View Object）：显示层对象，通常是 Web 向模板渲染引擎层传输的对象。 Query：数据查询对象，各层接收上层的查询请求。注意超过 2 个参数的查询封装，禁止使用 Map 类来传输。总结：这么多O，都搞晕了，感觉常用的就只有DTO；和表一一对应的类要不要后缀都不是很重要，所以DO也不是说很常用（当然有更好，能快速识别） xO 的使用方法总结：controller入参用dto，出参也是dto（从service层返回的）；service层入参是dto，出参dto；dao层入参不建议用dto而是分拆，出参dto或do。dao层接口不要用map作为入参，有不用map和list作为出参。 http(s) 传参的方式 常见如下 键值对：Content-Type 是 x-www-form-urlencoded 。准确说是 “名值对”，因为是可以重复的，如 ?favor=music&favor=reading 中的favor。 特殊情况 键值对传文件：Content-Type 是 form-data。跟 “键值对” 不同之处是可传文件传 JSON：Content-Type 是 application/json。注意和 “传JSON字串” 的表述区分开，后者是键值对的传参方式 ?jsonStr={} 路径参数：如 /user/9527，中的 9527 是路径参数 Controller 入参 参数少：采用 “键值对” 和 “路径参数”参数多、结构复杂：采用 “传JSON”。一般用 xxxReqDTO 接收 注意：有时不区分这么细，将 xxxReqDTO 和 xxxRespDTO 合并用同一个，叫 xxxDTO“传JSON” 的同时也可以使用键值对方式。即JSON字串在请求方法体里，键值对参数追加在URLController 出参 出参格式 一般总是返回200的 http 状态码，并用固定的返回类封装起来，例如 ResponseDTOResponseDTO 一般带有系统自定义的业务异常码、信息提示、时间、数据 出参从 Service 层获得，一般不再二次处理，直接放在 ResponseDTO 的 “数据” 里。无出参用 ResponseDTOService 层的入参 接收Controller层传入的简单类型或者 xxxReqDTO（或 xxxDTO）Service 层的出参 出参简单的，直接返回：如基本类型、包装类和String等 出参复杂的，返回 xxxRespDTO（或 xxxDTO） 注意：“返回 xxxRespDTO” 的表述也包括 List、PageInfo、Map等形式，下文不再赘述反例： 【禁止】有时贪快，用DO 作为出参，是不好的实践，必须用 DTO【疑惑】是不是每个Service接口都要定义自己的 DTO，DTO 可以跨不同的 Service 接口复用吗? 这个真的很纠结，复制一份DTO比较独立但是代码却重复非常多，用继承又导致复杂化不直观Dao 层（Mapper）的入参 简单和复杂的参数都分拆成基本类型、包装列和String等 insert接口或update接口会有很多字段，全列出来会不会很麻烦? 这些接口的sql不太可能自己写，因为代码生成框架可以自动生成的，所以不麻烦【建议】建议别用 Service 层的 xxxReqDTO（或 xxxDTO）作为入参，因为通常并非DTO里的所有字段在sql里会用到【疑惑】其实这个还是有点纠结的，要不要定义一个 xxxQuery 作为 mapper的查询入参? 反例： 【禁止】禁止入参用 Map【建议】建议入参也别用 xxxDO，因为xxxDO势必有很多字段其实并不是sql里需要的Dao 层（Mapper）的出参 简单的直接返回复杂的返回 xxxRespDTO（或xxxDTO） 【建议】能不能用 xxxDO 作为mapper的出参? 这块不强制禁止，因为生成的sql就是返回这些的 反例：禁止出参用 Map 或 List 其他思考 controller层：对此层大家的共识是不要写重的逻辑。但是要轻逻辑到什么程度? 比如我比较喜欢的一种方式是接口参数校验在参数声明中进行，但controller的方法的大括号里仅仅有一行调用service层的代码。这种方式把参数的进一步校验也交给service了。其实这种做法虽然很简洁，但是可能很难复用service层的接口。所以，是不是可以保证controller层有轻的 “分发” 性质的代码? 例如一个接口既可以新增也可以修改，在controller层里判断operType，新增的话分发到新增的service接口里，修改的话分发到修改的service接口里。controller里的RequestMapping，一般可能叫 “路由”、“路由地址”，这可能是来源于前端router的概念；其实也可以叫endpoint（端点），这个称呼更加显得后端其实我不太建议用 “路径参数”，会容易混淆 @GetMapping("/user/list") public List listUser(String name) {} 和 @GetMapping("/user/{name}") public List listUser2(@PathVariable("name") String name) {} 会符合 "精确匹配优先" 的原则，即访问/user/list匹配上面的，假设有个name是 "list" 值的，就没办法调用到下面的方法；如果是非 "list"，则匹配下面的方法。 ------------------------------ @GetMapping("/user/{name}") public List listUser2(@PathVariable("name") String name){} @GetMapping("/user/{id}") public QueryUserDTO queryUser(@PathVariable("id") Integer id){} 这两个方法能正常启动springboot，但是只有在运行时抛出异常，即无法确认要匹配哪个方法。因为前端的传参本质上是没有字串和整形的区分的，本质都是字串，只是在spring框架里如需要会进行转换。 * dao层的mapper接口真的不建议使用pojo作为入参，强烈建议把字段分拆成基本类型、包装类和String即可。原因是：1、这样清晰一点；2、一般入参的个数不会很多，比较多入参的insert接口都交给了代码生成，完全不需要自己写这样的sql。3、pojo作为入参，比如这个pojo是service层传如的xxxReqDTO，但是这个dto里并非所有字段都是sql里的条件，所以这会造成不好维护。 * dao层的mapper更加不建议用map作为入参，看似灵活，实际过于灵活导致难以分析真正传入的参数 * dao层的mapper接口出参也不建议用Map 或 List，看似灵活，实际也是过于灵活导致很难维护，比如从map中get值，key写错时很难发现。我们希望在编码的早期阶段尽快暴露出这些bug * service层的接口是可以调用其他同是service层的接口的。有时候为了共用接口，确实会有这样的需要。那被共用的接口是否要提取到类似CommonService里呢? 我建议是不需要不强制。 |
今日新闻 |
推荐新闻 |
| CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3 |